Managing energy transactions using distributed ledger technology

ABSTRACT

Methods and systems for originating and monitoring energy transactions using distributed ledger technology are provided. In one embodiment, a method is provided that includes receiving a first request to originate a contract associated with an energy transaction. The first request may include a first draft of the contract. A first transaction may be generated based on the first draft of the contract and may be added to a distributed ledger. Transaction information regarding the energy transaction may be received and a second draft of the contract may be generated based on the transaction information. A second transaction may be generated based on the second draft of the contract and may be added to the distributed ledger.

CROSS REFERENCE TO RELATED APPLICATION

The present application claims priority to U.S. Provisional ApplicationNo. 62/894,011, filed on Aug. 30, 2019, the disclosure of which isincorporated by reference for all purposes.

GOVERNMENT RIGHTS

This invention was made with government support under Award Number1951161, awarded by the National Science Foundation. The government hascertain rights in the invention.

SUMMARY

The present disclosure presents new and innovative systems for managingenergy transactions. In one aspect, a method is provided that includesreceiving, from a first computing device associated with a first partyof an energy transaction, a first request to originate a contractassociated with the energy transaction, wherein the first requestincludes a first draft of the contract and adding a first transaction toa distributed ledger, the first transaction generated at least in partbased on contents of the first draft of the contract. The method mayfurther include receiving, from at least one of the first computingdevice and a second computing device associated with a second party ofthe energy transaction, transaction information regarding the energytransaction. The method may also include generating a second draft ofthe contract based on the transaction information and adding a secondtransaction to the distributed ledger, the second transaction generatedat least in part based on contents of the second draft of the contract.

In a second aspect according to the first aspect, the method furtherincludes receiving, from at least one of the first computing device andthe second computing device, a request to finalize the contract andadding a third transaction to the distributed ledger, the thirdtransaction generated at least in part based on a finalized version ofthe contract.

In a third aspect according to the second aspect, the third transactionincludes (i) an identifier of the first party, (ii) an identifier of thesecond party, and (iii) a hash generated at least in part based on animage of the finalized version of the contract.

In a fourth aspect according to any of the first through third aspects,the method further includes receiving, prior to receiving the firstrequest, a second request to create the contract, wherein the secondrequest specifies a contract type and transmitting, to the firstcomputing device, a contract template associated with the contract type.

In a fifth aspect according to the fourth aspect, the method alsoinclude adding a fourth transaction to the distributed ledger, thefourth transaction generated at least in part based on the contracttemplate.

In a sixth aspect according to the fifth aspect, the fourth transactionincludes (i) an identifier of the first party and (ii) an identifier ofthe contract type.

In a seventh aspect according to any of the fourth through sixthaspects, generating the second draft of the contract includes adding thetransaction information to one or more corresponding fields within thecontract template.

In an eighth aspect according to any of the first through seventhaspects, the first transaction includes (i) an identifier of a firstparty associated with the first computing device and (ii) an identifierof the second party.

In a ninth aspect according to any of the first through eighth aspects,the transaction information includes trade volume information and/orprice information.

In a tenth aspect according to any of the first through ninth aspects,the first party is a seller and the second party is a buyer.

In an eleventh aspect according to the tenth aspect, the buyer isidentified using an auction system.

In a twelfth aspect according to any of the first though eleventhaspects, the second transaction includes (i) an identifier of the of thefirst party, (ii) an identifier of the second party, and (iii) a copy ofat least a subset of the transaction information.

In a thirteenth aspect according to any of the first through twelfthaspects, the method further includes executing one or more of anomination process, a confirmation process, a scheduling process, areconciliation process, billing and payment processes, and imbalanceresolution processes.

In a fourteenth aspect according to any of the first through thirteenthaspects, the method further includes storing, in a database, a copy ofat least one of the first draft of the contract, the second draft of thecontract, the first transaction and the second transaction.

The features and advantages described herein are not all-inclusive and,in particular, many additional features and advantages will be apparentto one of ordinary skill in the art in view of the figures anddescription. Moreover, it should be noted that the language used in thespecification has been principally selected for readability andinstructional purposes, and not to limit the scope of the disclosedsubject matter.

BACKGROUND

Millions of energy transactions occur daily on a system within energyproduction systems. Transaction participants may be energy or energyresource producers, energy or energy resource consumers, transportationor delivery providers, and/or independent third parties paid a fee tomanage transactions. Many companies still use antiquated energytransaction management systems, which can be complicated, monolithicinfrastructures that cause delays and prevent new revenue-generatingopportunities by blocking the timely flow of information.

BRIEF DESCRIPTION OF THE FIGURES

FIG. 1 depicts a transaction and fulfillment flow for participants in anatural gas value chain and corresponding transactions according to anexemplary embodiment of the present disclosure.

FIG. 2 depicts a transaction management flow for an energy transactionaccording to an exemplary embodiment of the present disclosure.

FIG. 3 depicts a system according to exemplary embodiments of thepresent disclosure.

FIG. 4 depicts a system for creating contracts for energy transactionsaccording to exemplary embodiment of the present disclosure.

FIGS. 5A-5D depict stages of a process for originating, negotiating andexecuting an energy transaction according to an exemplary embodiment ofthe present disclosure.

FIG. 6 depicts a method for originating, negotiating and executing acontract for an energy transaction according to an exemplary embodimentof the present disclosure.

FIG. 7 illustrates a computing system, according to an exemplaryembodiment of the present disclosure.

DETAILED DESCRIPTION OF EXAMPLE EMBODIMENTS

Aspects of the present disclosure involve systems and methods fororiginating, negotiating and executing energy transactions usingdistributed ledger technology and/or interactive smart contracts. Forexample, the disclosed system may facilitate originating, negotiationand execution of contracts for energy transactions such as a buy/sellagreement at a receipt point, a shipping agreement on a pipeline ordistribution company from receipt to delivery point, a buy/sellagreement at a delivery point, and/or any other energy transactioninvolving multiple participants.

In various aspects, the disclosed system implements techniques thatutilize distributed ledger technology (DLT) to aggregate the receipt,shipment, and/or delivery requirements for all participants in an energytransaction (e.g., within a contract for the energy transaction). Forexample, DLT may include blockchain implementations, such as publicblockchains or private blockchains. It should be understood thatreferences to “blockchain” within the present disclosure may correspondto DLT generally, blockchain technology, or both. For example, theenergy transaction may concern natural gas, oil, electricity, or anyother type of energy, energy source, or energy-related item or service.The system may execute to optimize the receipts, shipments, anddeliveries for all participants in a transaction. For example, thesystem may recognize the receipt and delivery priorities, commoditycosts, shipping costs, fuel, and other costs and requirementscontractually agreed or specified by all participants in an energytransaction. In one aspect, the system employs the combination ofblockchain (a type of DLT) and interactive smart contracts to enabletransaction negotiation, storage, and verification instantly across anetwork, which may reduce operating costs, enable more secure storageand management of transaction data, and improve the speed of energytransaction processing. The system may determine the appropriate periodof nomination and the cycle during which the nomination should besubmitted for a transaction and may submit the nomination as needed. Anytransaction participant may observe the status of the transaction at anytime via the blockchain.

In various aspects, energy transactions as discussed herein may includeany transaction concerning one or more energy resources. For example,energy transactions may include production of, transportation of,financing of, delivery of, storage of, and/or usage of energy or energyresources. For example, energy resources may include natural gas, oil,or oil derivatives, energy production equipment, electricity, solarpanels, wind turbines, particular quantities, or amounts of energy.Additional or alternative types of energy transactions and/or types ofenergy resources may be readily apparent to one skilled in the art basedon the contents of the present disclosure. All such energy transactionsand energy resources are hereby contemplated within the scope of thepresent disclosure. Furthermore, the examples discussed herein focus onenergy transactions concerning natural gas. It should be understood thatsimilar techniques may be used to process any type of energy transaction(or other types of transaction unrelated to the energy industry).

FIG. 1 depicts a transaction and fulfillment flow 100 for participantsin an energy transaction. In particular, FIG. 1 may depict a transactionand fulfillment flow 100 for participants in energy transactionconcerning the extraction, purchase and delivery of natural gas. Thetransaction and fulfillment flow 100 includes a transaction manager 102,who may be responsible for monitoring fulfillment and compliance withthe energy transaction for natural gas. For example, the transaction andfulfillment flow 100 includes an energy producer 104,106 and 108, agatherer 110, a refinery 112, a transmission pipeline 116, a localdistribution center 122, and customers 126, 128, 130, who may all beparties to the energy transaction. The gatherer 110 may be responsiblefor gathering natural gas from various wellheads 104, 106, 108. Naturalgas may then be provided to a refinery 112, who may refine the naturalgas into a usable product. Natural gas may then proceed through atransmission pipeline 116 to the local distribution center 122. Thetransmission pipeline 116 may be associated with one or more undergroundstorage facilities 118 and/or liquid natural gas (LNG) liquificationfacilities 120. Liquid natural gas may be more compact and accordinglyeasier to transmit than gaseous natural gas. Additionally oralternatively, natural gas may need to be stored in liquid or gaseousforms during transmission to the local distribution center 122.Accordingly, the transmission pipeline 116 may include one or moreunderground storage facilities 118.

Once received by the local distribution center 122, the natural gas maybe distributed to customers 126, 128, 130. In particular, the localdistribution center may have different types of customers, includingindustrial customers 126 (e.g., industrial plants or factories usingnatural gas), commercial customers 128 (e.g., offices, stores, or othercommercial business facilities), and residential customers 130 (e.g.,homes, apartments, apartment complexes). Certain customers may be partyto the energy contract. In particular, certain industrial customers 126and commercial customers 128 may be party to the energy transaction andmay accordingly be monitored by the transaction manager 102. Thecustomers 126, 128, 130 may receive the natural gas from the localdistribution center 122 via one or more distribution pipelines 124.

As can be seen in the legend 132, each stage of the transaction andfulfillment flow 100 includes different required tasks and services toensure the transaction is being fulfilled accurately and completely. Inparticular, metering services (e.g., determining the amount of naturalgas entering and/or leaving) are required at the wellheads 104, 106,108, the transmission and distribution pipelines 116, 124, theunderground storage facility 118, the liquification facility 120, andthe customers 126, 128, 130. Additionally, measurement services (e.g.,measuring the purity and/or quality of natural gas entering and/orleaving) are required at the wellheads 104, 106, 108, the gatherer 110,the refinery 112, the transmission pipeline 116, the underground storagefacility 118, the liquification facility 120, and the distributionpipeline 124. Control services (e.g., distributed control system (DCS)and/or supervisory control and data acquisition (SCADA) systems forautomating plants or other production facilities) may be required at thewellheads 104, 106, 108, the gatherer 110, the refinery 112, thetransmission pipeline 116, the underground storage 118, theliquification facility 120, the local distribution center 122, and thedistribution pipeline 124. Security and surveillance services mayfurther be required at the gatherer 110, the refinery 112, thetransmission pipeline 116, the underground storage 118, theliquification facility 120, and the distribution pipeline 124.Furthermore, forecasting, simulation, optimization, and/or enterpriserelationship management (ERP) services may be required at various pointsin the transaction and fulfillment flow 100. For example, forecasting,simulation, optimization, and/or ERP services may be required by thetransmission pipeline 116 and the distribution pipeline 124. As anotherexample, the transaction manager 102 may use forecasting, simulation,optimization, and/or ERP services to determine whether the transactioncan be fulfilled (e.g., based on current commodity availability andshipping capacity by the gatherer 110, current inventory levels,customer demand, and the like or current shipping capacity of thetransmission pipeline 102).

It should be appreciated that the transaction fulfillment flow 100depicted in FIG. 1 and discussed above is merely exemplary. For example,in additional or alternative implementations, transaction managementflows for natural gas transactions may include additional servicesperformed by each of the parties to the energy transaction and/or mayexclude one or more of the above-discussed services. Additionally oralternatively, transaction flows may similarly be used to monitordifferent types of energy transaction (e.g., energy transactions fordifferent types of energy).

As can be appreciated in the transaction flow 100, the production,delivery, and consumption of energy may require many energy transactionsbetween multiple different parties. For example, there may be separatecontracts with separate requirements for energy transactions at each ofthe operations in the transaction flow 100. Furthermore, each of theenergy transactions may have two or more parties.

FIG. 2 depicts a transaction management flow 200 for an energytransaction according to an exemplary embodiment of the presentdisclosure. In particular, FIG. 2 may depict a transaction managementflow 200 for a buy/sell agreement on a pipeline or distribution companyfrom receipt to delivery point, and a buy/sell agreement at a deliverypoint. The transaction management flow 200 includes three type oftransactions, all of which may correspond to one or more of thetransaction steps in the transaction and fulfillment flow 100. Asupplier and shipper transaction is depicted where the supplier is theseller of the energy resource (e.g., an energy commodity) and theshipper is the buyer. A shipper and transporter transaction is depictedwhere the transporter is the seller of the energy resource (e.g.,shipping capacity) and the shipper is the buyer. A shipper and customertransaction is depicted where the shipper is the seller of the energyresource (e.g., the energy commodity) and the customer is the buyer ofthe energy resource.

FIG. 3 depicts a system 300 according to exemplary embodiments of thepresent disclosure. The system 300 may be configured to receive andprocess information regarding energy transactions (e.g., negotiationinformation, status information, fulfillment information, securityinformation, and the like) to execute actions via smart contracts and tointegrate with a distributed ledger to store the information ordetermine whether the information indicates compliance with a previouslynegotiated energy transaction. The system 300 includes a businessapplication layer 302, a middleware layer 308, and a distributed ledgerand machine learning layer 314.

The application layer includes horizontal applications (“apps”), whichmay be software services or processes executing on computing devices toprovide front-end services, integration services, and the like. Inparticular, the applications may enable the system 300 to integrate withthe information technology (IT) systems of users or entitiesnegotiating, contracting, or monitoring compliance for an energytransaction. In particular, the application layer 302 may includehorizontal software as a service (SaaS) applications 306 and horizontalblockchain as a service (BaaS) applications 304. The SaaS applications306 may be configured to integrate services provided by the system 300(e.g., by the middleware layer 308 and/or the distributed ledger andmachine learning layer 314) with IT systems associated with users orother entities accessing the system 300. The BaaS applications 304 mayprovide services that improve access to, visualization of, andintegration with distributed ledger technologies used by the system 300.For example, the BaaS applications 304 may provide integration servicesthat allow users to view a distributed ledger containing transactionsrelated to an energy transaction. As another example, the BaaSapplications 304 may enable users to create or view individual entries(i.e., individual transactions) on a distributed ledger related to aparticular energy transaction.

The middleware layer 308 may be configured to provide a communicativeinterface between the business application layer 302 and the distributedledger and machine learning layer 314. For example, the middleware layer308 includes distributed ledger gateways and adapters 310 and predictiveanalytics services 312. The distributed ledger gateways and adapters 310may be configured to provide communicative services between the BaaSapplications 304 and distributed ledgers storing information related toan energy transaction. For example, the distributed ledger gateways andadapters 310 may receive a request from a BaaS application 304 to viewtransactions on a distributed ledger related to a particular energytransaction. The distributed ledger gateways and adapters 310 may beconfigured to communicate with the distributed ledger to identifycorresponding transactions and to provide copies of the identifiedtransactions to the BaaS applications 304. The predictive analyticsservices 312 may provide data analysis, machine learning, artificialintelligence, and similar services for use in analyzing data related toenergy transactions. For example, the predictive analytics services 312may include statistical analysis libraries, artificial intelligencelibraries, machine learning libraries, applications configured toperform data analysis, machine learning, or artificial intelligenceanalysis, and the like.

The distributed ledger in the distributed ledger and machine learninglayer 314 may be configured to directly interact with one or moredistributed ledgers storing information regarding energy transactionsand/or to provide machine learning or other data analysis services. Forexample, the distributed ledger and machine learning layer 314 includesa distributed ledger stack 316. The distributed ledger stack 316 may beconfigured to interact with and/or at least partially implement adistributed ledger that is used to store and verify energy transactioninformation. For example, the distributed ledger stack 316 may act as anode of the distributed ledger and/or may interact with or otherwiseinterface with nodes of the distributed ledger. In addition, thedistributed ledger and machine learning layer 314 includes a virtualmachine layer 318, a consensus layer 320, and a peer-to-peer (P2P)network layer 322. A virtual machine layer 318 may implement one or morevirtual computing devices (e.g., virtual processors, virtual memories)configured to execute as nodes of a distributed ledger and/or configuredto execute software or applications to directly interface with nodes ofa distributed ledger. For example, nodes of the distributed ledger maycommunicate using the P2P network layer 322, which may providecommunication services according to one or more P2P communicationprotocols (e.g., the BitTorrent protocol, the Bitcoin P2P protocol, theAdvanced Peer-to-Peer Networking (APPN) protocol, and the like). Theconsensus layer 320 may be used to negotiate consensus according tovarious distributed ledger configurations. For example, the consensuslayer 320 may be used to negotiate between nodes of a distributed ledgerto verify valid transactions to add to the distributed ledger, therebyreaching consensus. As a specific example, the consensus layer 320 mayimplement one or more consensus protocols such as a proof of workconsensus protocol, proof of stake consensus protocol, delegated proofof stake consensus protocol, practical Byzantine fault toleranceprotocol, ripple protocol, and the like. Transactions received to beadded to a distributed ledger may first have to be validated accordingto the consensus protocol before being added to the distributed ledger(e.g., within a block of the distributed ledger). The proposed approachis designed to be utilized in any type of current and future version ofDLT.

The distributed ledger and machine learning layer 314 may also includehistorical data 324. Historical data 324 may be used by the predictiveanalytics services 312. For example, the historical data 324 may storedata regarding energy transactions, interactions with the distributedledger, negotiations regarding energy transactions, compliance dataassociated with energy transactions, or any other operations performedby the system 300 (or discussed herein). In particular, the historicaldata 324 may be stored in one or more databases 326. In certaininstances, the historical data 324 may additionally or alternatively bestored on a distributed ledger. For example, data stored by the system300 (or any other system discussed herein) may be stored using adistributed file system, such as an InterPlanetary File System (IPFS).IPFS is a peer-to-peer distributed file system that may be used toconnect stored data to a common distributed ledger infrastructure. Suchdistributed file system implementations may be preferable to moreconventional storage techniques (e.g., server-based and/or localdatabases). For example, IPFS has no single point of failure and nodesimplementing the distributed ledger used to store the data do not needto trust each. Furthermore, distributed file systems may supportdistributed content delivery, which saves bandwidth and prevents directdenial of service (DDoS) attacks, which other data communicationprotocols (e.g., HTTP) may remain vulnerable to.

FIG. 4 depicts a system 400 for creating contracts (e.g., conventionalcontracts, smart contracts) for energy transactions according toexemplary embodiment of the present disclosure. The system 400 includesa front-end user interface 402, proxy service 410, a middleware layerAPI 412, and a distributed ledger layer 414. The front-end userinterface 402 may be configured to provide one or more interfaces usedto negotiate, prepare, and/or execute energy transaction contracts. Forexample, the front-end interface 402 includes a seller interface 404 anda buyer interface 406. Interfaces 404, 406 provided by the front-endinterface 402 may include graphical interfaces (e.g., as depicted)and/or other types of interfaces (e.g., text-based interfaces, commandline interfaces). In certain instances, the interfaces 404, 406 may beaccessible via a web interface. In additional or alternative instances,the interfaces 404, 406 may be accessible via local software, smartphoneapplications, command line applications, and the like. The front-enduser interface 402 also includes a communication interface 408. Thecommunication interface 408 may be used to provide synchronous orasynchronous communication services between the interfaces 404, 406provided by the front-end user interface 402. For example, thecommunication interface 408 may enable the seller interface 404 tocommunicate with the buyer interface 406 using one or more communicationprotocols, such as the hypertext transfer protocol (HTTP), the advancedmessage queueing protocol (AMQP), and the like.

The proxy service 410 may be configured to facilitate communicationbetween the front-end user interface 402 and the middleware layer API412. For example, the proxy service 410 may provide one or both ofload-balancing services and static caching services. For example, themiddleware layer API 412 may be implemented by one or more computingdevices, and the proxy service 410 may provide load-balancing servicesby selecting particular computing devices that implement the middlewarelayer API 412 used to provide services to particular instances of thefront-end user interface 402 based on current operating loads (e.g.,computing resource usage, processor usage, memory usage). For example,the proxy service 410 may select a particular computing device such thatthe average operating loads are balanced across the computing devicesimplementing the middleware layer 412. The proxy service 410 may alsoprovide static caching services that store one or more resourcesutilized by the front-end interface 402 for quick retrieval by thefront-end interface 402. For example, the proxy service 410 may interactwith a static file deployment 420. For example, the static filedeployment 420 may implement a file storage system 422 (e.g., a localdatabase, a database implemented by one or more servers, a distributeddatabase implemented at least in part by a blockchain). For example, thefile storage system 422 may store templates (e.g., contract templates)used by the front-end user interface 402.

The middleware layer API 412 may be configured to provide multipleservices used in creating, negotiating, validating, executing, storing,and monitoring compliance of energy transactions and corresponding smartcontracts in interactive manner. In particular, the middleware layer API412 includes a contract template verification service 426, a businesslogic/rule engine 428, a contract image generation service 430, adynamic form generation service 432, a DLT client standard developmentkit (SDK) 434, a certificate authority SDK 436, a transaction managementservice 438, and a DLT node management service 440. The contracttemplate verification service 426 may be used to verify one or moreaspects of negotiated contracts prior to execution of the contract. Forexample, the contract template verification 426 may be configured toensure that a proper contract template is used to negotiate an energytransaction. As a specific example, the contract template verificationservice 426 may be configured to ensure that the proper contracttemplate is used for a particular energy resource or service (e.g., oil,natural gas or buy/sell, transportation) of the energy transaction.

The dynamic form generation service 432 may provide schema specificationfor the energy transaction and may serve as an endpoint for the sellerand buyer interfaces 404, 406. For example, the schema specification mayidentify types of data that can be added to a contract template for theenergy transaction. For example, information (e.g., buyer information,seller information, trade volume information, price information,delivery point information) may be added to the contract template duringnegotiation and preparation of the contract. The schema may specifywhich types of data may be added to the contract template and where theinformation is included within the contract template (e.g., within thetext of the contract template) to generate a final contract.Furthermore, by creating an endpoint for the seller and buyer interfaces404, 406, both the seller and buyer (and any other parties of thetransaction) may be able to view data added to the contract as thecontract is negotiated.

The contract image generation service 430 may be configured to generateimages of finalized contracts. Once a contract is agreed to by theseller and the buyer, the contract may be finalized as an image of thefinalized copy of the contract (e.g., the contract templateincorporating any data added during negotiation and preparation, buyerand seller information, buyer and seller signature). The contract imagegeneration service 430 may then store the image of the finalized copy ofthe contract. For example, the contract image generation service 430and/or the middleware layer API 412 may communicate with an elastic filestorage 424. The elastic file storage 424 images of finalized contracts,along with corresponding information (e.g., a transaction identifier,buyer information, seller information). In certain instances, thecontract image generation service 430 may include a hash correspondingto a transaction or block on a distributed ledger corresponding to thefinalized copy of the contract.

The DLT client SDK 434 may provide communication services with thedistributed ledger layer 414. For example, the DLT client SDK 434 mayprovide communication services to commit, query, and verify data storedon a distributed ledger 450 of the distributed ledger layer 414. Asexplained further below, one or more transactions may be added to thedistributed ledger 450 during the creation, negotiation, andfinalization process for a contract of an energy transaction. The DLTclient SDK 434 may be used by other services provided by the middlewarelayer 412 to communicate with the distributed ledger 450 to add thetransactions (e.g., after consensus is reached by one or more nodesimplementing the distributed ledger). Additionally or alternatively, oneor more services of the middleware layer API 412 may retrieve and/orverify data stored on the distributed ledger 450. In such instances, theDLT client SDK 434 may also provide communication services with thedistributed ledger 450.

The certificate authority SDK 436 may provision and verify certificatesto individual parties to energy transactions (e.g., parties negotiatinga contract, third parties of the energy transaction, attorneys or otherrepresentatives of parties to the energy transaction) and/or tocomputing services interacting with the distributed ledger 450. Whenadding transactions to the distributed ledger 450, the transactions maybe required to be signed by a valid certificate. Accordingly, acertificate may be received from one or more parties to energytransaction (e.g., a seller, a buyer) and included within a transactionto be stored on the distributed ledger 450. Prior to providing thetransaction to the DLT client SDK 434 for storage on the distributedledger 450, the certificate authority SDK 436 may be used to verify thatthe certificate(s) included within the transaction are valid (e.g., wereissued to the one or more parties by the certificate authority SDK 436and/or another certificate issuing authority).

The business logic/rule engine 428 may be configured to automaticallyapply business logic during fulfillment of the energy transaction. Forexample, the business logic/rule engine 428 may be used to configurebusiness logic that automatically implements at least a part of theinteractive smart contract as the energy transaction is fulfilled. As aspecific example, payment under the contract may be staged such thatpayment automatically issues when particular percentages (e.g., 25%,50%, 75%, 100%) of an energy resource is delivered by the seller to thebuyer. In such instances, as proof is provided that a particularpercentage of the energy resource was delivered, the business logic maybe executed by the business logic/rule engine 428 to verify the proofand to automatically trigger or complete payment under the contract. Incertain instances, the business logic created by the business logic/ruleengine 428 may be implemented as an interactive smart contract executingon the distributed ledger 450. For example, the interactive, code-basedsmart contract may be implemented using a protocol (e.g., the Ethereumprotocol and the like) configured to be executed on a blockchain (e.g.,the Ethereum blockchain, a private blockchain, and the like).

The transaction management service 438 may be configured to monitorstorage of transactions on the distributed ledger 450. For example, thetransaction management service 438 may be configured to ensure that anewly-added transaction is properly stored in a new block of thedistributed ledger 450, and that the newly-added transaction isreflected on the blocks stored on all nodes implementing the distributedledger. If one or more nodes of the distributed ledger 450 failed toproperly store the newly-added transaction, the transaction managementservice 438 may invalidate any stored copies of the newly-addedtransaction. For example, the transaction management service 438 may addan invalidation transaction to the distributed ledger 450, indicatingthat any previously stored copies of the newly-added transaction areinvalid and should not be acted on (e.g., by smart contracts concerningthe energy transaction). The transaction management service 438 mayadditionally or alternatively provide a notification to the sellerand/or the buyer (e.g., via the interfaces 404, 406) that indicates thenewly-added transaction was not successfully stored on the distributedledger 450 and needs to be attempted again.

The DLT node management service 440 may be responsible for managing thenodes that implement the distributed ledger 450. For example, the DLTnode management service 440 may receive notifications (e.g., fromcomputing devices implementing the nodes) as nodes are added to orremoved from implementing the distributed ledger 450 (e.g., removed fromor added to a network of computing devices responsible for implementingthe distributed ledger 450). In particular, the DLT node managementservice 440 may communicate with a node management API executing on thenodes to determine when nodes are added to or removed from implementingthe distributed ledger 450. In certain instances, the DLT client SDK 434may communicate with the DLT node management service 440 to identifywhich nodes can be communicated with to add transactions to thedistributed ledger 450.

The middleware layer API 412 may be configured to communicate with oneor more servers while implementing the above-described services. Forexample, the system 400 also includes a database server 416 implementinga data storage 418. One or more of the services discussed above may beconfigured to store data in the data storage 418 and/or to receive datafrom the data storage 418.

Additionally or alternatively, further services provided by middlewarelayer API 412 may be readily apparent to one skilled in the arts inlight of the present disclosure. All such additional or alternativeservices are hereby contemplated within the scope of the presentdisclosure.

The distributed ledger layer 414 may be configured to implement thedistributed ledger 450. In particular, the distributed ledger layer 414includes nodes 442, 444, 446, may be configured to implement thedistributed ledger 450 according to one or more distributed ledgerprotocols (e.g., a blockchain protocol, the Ethereum protocol, thebitcoin protocol). In certain instances, one or more of the nodes may beimplemented by computing devices associated with one or more parties ofan energy transaction. For example, the node 442 may be implemented by aseller in an energy transaction, the node 444 may be implemented by abuyer in an energy transaction, and the node 446 may be implemented by athird party agent (e.g., a mediator, a disinterested third party, andthe like).

Additionally, the distributed ledger layer 414 includes a businesslogic/chaincode service 448. The business logic/chaincode service 448may be configured to monitor for business logic (e.g., interactive smartcontracts) executing on the distributed ledger 450. The businesslogic/chaincode service 448 may then analyze transactions for dataindicating compliance with the business logic and may perform additionalactions (e.g., processing payments and/or transfers (e.g., electronicfunds or cryptocurrency transfers) in accordance with the conditionsidentified within the business logic (e.g., interactive smartcontracts).

All or part of the system 400 may be implemented by a computing device.For example, the front-end user interfaces 402, the proxy service 410,the middleware layer API 412, the distributed ledger layer 414 (e.g.,the nodes 442, 444, 446), the static file deployment 420, the filestorage system 422, database server 416, the data storage 418, and/orthe elastic file storage 424 may be implemented by one or more computingsystems. As a specific example, the one or more computing systems mayinclude one or more processors and/or one or more memories. The one ormore memories may store instructions which, when executed by the one ormore processors, cause the one or processors to implement at least oneoperational feature of the front-end user interfaces 402, the proxyservice 410, the middleware layer API 412, the distributed ledger layer414 (e.g., the nodes 442, 444, 446), the static file deployment 420, thefile storage system 422, database server 416, the data storage 418,and/or the elastic file storage 424.

FIGS. 5A-5D depict stages 500, 520, 530, 540 of a process fororiginating, negotiating and executing an energy transaction accordingto an exemplary embodiment of the present disclosure. The stages 500,520, 530, 540 may be performed by a computing system, such as the system400. In the stage 500, a first user may select (e.g., at operation 502)a contract type via the seller interface 404 (e.g., using a contracttype button of the seller interface 404). For example, the first usermay represent a selling party for an energy transaction and may selectfrom a plurality of contract types. In one specific example, an energytransaction includes the sale and/or delivery of natural gas, althoughother examples may concern different types of energy resources. Fornatural gas transactions, the contract types may include one or more ofbuy/sell agreements, firm transportation agreements (FT), interruptibletransportation agreements (IT), pooling agreements, park and loanagreements (PAL), storage agreements, and the like.

Each of the contract types may have one or more associated contracttemplates. Templates may be prepared by attorneys and business expertsto incorporate and/or comply with requirements applicable to thedifferent types of requirements applicable to energy transactions (e.g.,legislative requirements, regulatory requirements, businessrequirements). Contract templates may include standardized form wordingof the actual business contract, but may exclude transaction specificinformation for the energy transaction (e.g., information of thetransacting parties, transacting energy resource or service, price,quantity information, receipt/delivery point, and the like).

After a contract type is selected, a corresponding template may bereceived from the file storage 422 of the static file deployment 420(e.g., at operation 504). For example, each contract type selectable bythe first user may have a particular unique identifier and acorresponding template may be stored in the file storage 422 of thestatic file deployment 420 (e.g., stored in association with theparticular unique identifier). After a contract type is selected, acorresponding contract template 510 may be identified within the filestorage based on the unique identifier associated with the selectedcontract type. Additionally or alternatively, contract templates 510 maybe stored within a distributed ledger, such as a file storage deploymenton the distributed ledger 450. The static file deployment 420 may thentransmit the corresponding contract template to the seller interface 404(e.g., to a computing device implementing the seller interface 404). Forexample, the seller interface 404 may receive the contract template 510via the proxy service 410. Once received, the contract template 510 maybe updated to include an identifier of the seller (e.g., an emailaddress of the seller, a name of the seller, a unique identifier of theseller and the like). In certain instances, the identifier of the sellermay include a unique identifier issued by the certificate authority SDK436 and/or the horizontal BaaS apps 304.

The first user may then originate the contract (e.g., operation 506) byselecting the originate contract button. Originating the contract mayinclude adding a first transaction to the distributed ledger 450 (e.g.,via the distributed ledger layer 414. The first transaction may be addedin a first block 508 of the distributed ledger 450. The firsttransaction may include (i) an identifier of the seller and (ii) anidentifier of the selected contract type (e.g., selected contracttemplate 510). For example, identifiers of the seller and/or selectedcontract type may be stored as metadata of the first transaction.

Turning to stage 520 and FIG. 5B, a buyer may be selected (e.g., atoperation 522). The buyer company may be selected when the first userselects the company selection button of the seller interface 404. Thebuyer company may be selected based on one or more unique identifiers ofthe buyer (e.g., an email address of the buyer, a name of the buyer, aunique identifier of the buyer, and the like). Once the buyer company isselected, an identifier of the buyer may be added to the contracttemplate (e.g., within one or more fields of the contract template). Incertain instances, rather than having the first user individuallyidentify the buyer, alternative mechanisms (e.g., auction mechanisms)may be used to identify a buyer willing to pay a specified price for theenergy resource and/or energy transaction.

The updated contract may then be transmitted to the buyer (e.g., atoperation 524). For example, the seller interface 404 and the buyerinterface 406 may communicate via the communication interface 408. Theupdated contract may include identifiers of the buyer and the selleradded to corresponding fields of the contract template received atoperation 504.

A second transaction may then be added to the distributed ledger 450.For example, the second transaction may be added to a second block 526of the distributed ledger 450. The second transaction may include (i) anidentifier of the seller, (ii) an identifier of the buyer, and (iii) anidentifier of the contract type. In certain implementations, the secondtransaction may also include a copy of the updated contract and/or ahash of the updated contract. Furthermore, the identifier of the buyermay include a unique identifier issued by the certificate authority SDK436 and/or the horizontal BaaS apps 304.

Turning to stage 530 and FIG. 5C, transaction information may be addedto the contract (e.g., at operation 532). For example, transactioninformation may be received via the seller interface 404 and/or thebuyer interface 406. In one specific instance, transaction informationincluding trade volume for the energy resource, price information forthe energy resource, and delivery-point information for the energyresource. In additional or alternative implementations, all or part ofthe transaction information may be received via the buyer interface 406.After one party (e.g., the seller) enters all or part of the transactioninformation, an updated version of the contract may be generated thatincorporates the provided transaction information. For example, a tradevolume may be received and copies of the trade volume may be added tocorresponding fields within the contract template. The party may clickthe negotiate contract button (e.g., at operation 534) to present anupdated copy of the contract to the other party (e.g., via thecommunication interface). The updated contract may then be transmitted(e.g., at operation 536) to the other party (e.g., the buyer). Theupdated contract may include one or more smart contract features (e.g.,smart contract code representative of proposed contract terms),simplifying the transmittal of review of contracts under negotiation. Incertain implementations, a third transaction may be added to thedistributed ledger 450. For example, the third transaction may be addedto a third block 538 of the distributed ledger 450. The thirdtransaction may include (i) an identifier of the seller, (ii) anidentifier of the buyer, (iii) an identifier of the type of contract,(iv) indications of received transaction information, and/or (v) anagreement status (e.g., under negotiation, awaiting buyer action,awaiting seller action).

One or more of the operations 532, 534, 536 may be repeated. Forexample, all required transaction information may not be received fromthe seller interface 404. In such instances, further transactioninformation may be received from the buyer, which may repeat one or moreof the operations 532, 534, 536 to generate an updated version of thecontract, transmit the updated copy to the seller interface 404, and adda further transaction to the distributed ledger 450.

Turning to stage 540 and FIG. 5D, once all transaction information isreceived, one or both parties to the energy transaction may execute thecontract (e.g., at operations 542, 544). For example, the first userassociated with the seller and a second user associated with the buyermay both be required to click an execute final contract button in theseller interface 404 and the buyer interface 406. In a further example,the seller and buyer interfaces 404, 406 may not make the execute finalcontract button available until after all required transactioninformation is provided by one or both of the seller and the buyer(e.g., or associated users). For example, the contract template receivedmay specify particular types of transaction information (e.g., tradevolume, price, delivery point) that are required for a contractregarding the specified type of energy transaction. The interfaces 404,406 may compare received transaction information to the requiredtransaction information and may make the execute final contract buttonavailable when all required transaction information is received.

Once the contract is executed, a finalized copy of the contract may bestored. For example, an image of the finalized copy of the contract maybe generated (e.g., by a contract image generation service 430 and maybe stored in the elastic file storage 424 or another storage system), asexplained above. Additionally or alternatively, a fourth transaction maybe stored in the distributed ledger 450. For example, the fourthtransaction may be stored in a fourth block 550 of the distributedledger 450. The fourth transaction may include (i) an identifier of theseller, (ii) an identifier of the buyer, (iii) an identifier of thecontract type, (iv) indications of the received transaction information,and/or (v) an agreement status (e.g., finalized). Additionally oralternatively, the fourth transaction may include a unique identifier ofthe finalized contract (e.g., a hash of an image of the finalizedcontract). Once the fourth transaction is added to the distributedledger 450 and/or a copy of the finalized contract is stored in theelastic file storage 424, the process for negotiating the energytransaction may be complete.

In the above-described examples, the contract negotiation procedureswere initiated by the seller. In additional or alternative instances,contract negotiation procedures may be implemented by another party,such as the buyer, transporter or transaction manager. Furthermore, incertain implementations, one or more of the transactions added to theblockchain may be omitted. As a specific example, certainimplementations may omit the first transaction added to the first block508. Additionally, as depicted, the blocks 508, 526, 538, 550 aresequential. It should be understood that, in practice, these blocks maynot be added sequentially to the distributed ledger and that additional,intervening blocks may also be added to the distributed ledger betweenone or more of the blocks 508, 526, 538, 550.

The process described above in the stages 500, 520, 530, 540 may enabledetails regarding energy transactions and corresponding contracts to bestored in a distributed ledger 450. In particular, the transactionsadded to the distributed ledger in response to the negotiation andexecution of contracts corresponding to energy transactions may reducethe overall amount of data that is required to be stored in the disputedledger 450. For example, rather than storing complete copies ofparticular contracts, the transactions as described above may storeinformation included within one or more template fields of a contracttemplate corresponding to the identified type of energy transaction andcorresponding contract template. Based on this information, and usingthe corresponding contract templates, a complete copy of the executedcontract may be reconstructed from data stored in the distributed ledgereven if a contract template may be retrieved from the static filedeployment 422 and/or the file storage system 422 and may be combinedwith the information stored within transactions of the distributedledger to generate a new, complete copy of the contract for the energytransaction. Such implementations can improve scalability for certainimplementations of the system 400, for example implementations relyingon privately-hosted blockchains or blockchains with high data storagecosts. As a further example, by reducing the overall storage required onthe distributed ledger, the above-discussed techniques may improvescalability for transaction negotiation systems.

Additionally, these techniques may not depend on implementation detailsfor particular types of distributed ledgers and may accordingly be usedto combine one or more different types of distributed ledgers, providingcross compatibility for energy transaction and related contract storage.The proposed approach may function in any DLT or similar technologywhich may or may not have an interactive smart contract feature. If theabove techniques are implemented using a distributed ledger thatsupports smart contracts, the contract may execute in a hybrid (e.g.,code-based and text-based) interactive smart contract mode in on andoff-chain domains. If the above techniques are implemented using adistributed ledger that does not support smart contracts, the contractmay function as off-chain and text based smart contract where the coredata is kept as metadata in a distributed ledger as an immutable recordof the finalized contract. Furthermore, as explained above, storedcontracts may be combined with interactive smart contracts executingautomatically within the distributed ledger to ensure compliance withconditions specified within the contract.

Furthermore, transactions relating to the same agreement may be linked.As a specific example, subsequent transactions stored on the distributedledger by the system 400 may include identifiers of previously-storedtransactions relating to the same agreement. Furthermore, whereadditional security is required, all or part of the contents of thetransactions may be encrypted prior to storage on the distributed ledger450.

In addition, because new transactions may be added to the blockchain asthe parties exchange updated drafts of a contract (e.g., based ondiffering transaction information inputs), the above-described processmay enable interactivity via the distributed ledger. This may preserve acopy of negotiations, which may be accessible to parties seeking toconfirm previous negotiation offers and/or agreed-upon terms.Furthermore, this interactivity may combine agreement storage with smartcontract logic, allowing agreements to be automatically implemented atleast in part.

Furthermore, the above-described process may be combined with one ormore additional features. As one specific example, credit informationfor one or more parties of the energy transaction may be monitored. Forexample, credit information may be used by a selling party to establisha credit limit for a buying party, which may be included within afinalized copy of a contract between the selling party and the buyingparty.

As another example, predictive contracting services may be used tofacilitate negotiation of the contract. For example, one or more machinelearning models may be used to predict the transaction informationincluded within the contract (e.g., subject to review and approval byone or more parties to the energy transaction). As a specific example,the machine learning model may analyze one or more of the followingparameters: meteorological parameters (e.g., temperature, wind speed,precipitation, and humidity), measurement parameters from an energyinstallation (e.g., metering and other production data from SCADA andDCS systems at the energy installation), financial parameters (e.g.,credit information for one or more parties of the energy transaction),and other operational parameters concerning an energy resource of theenergy transaction. The machine learning model may include one or moremachine learning models, such as one or more artificial neural networks(ANN), support vector machines (SVM), Gradient Boosting Trees, and thelike. The machine learning model may be trained to predict transactioninformation, such as trade volume, price, transportation capacity, pricevolatility, anticipated future demand, anticipated future production,and the like. Final predicted quantities for the transaction informationmay be added to a draft of the contract and provided to one or moreparties of the transaction or may be added to a corresponding userinterface for review by one or more parties. Additionally oralternatively, one or more machine learning models may be configured tomonitor and/or correct smart contracts executing on the distributedledger to implement the energy transaction. For example, machinelearning models may analyze information provided to prove compliancewith the energy transaction to detect when fraudulent information issubmitted (e.g., fraudulent payment information, fraudulent energyresource delivery information, and the like). In still furtherimplementations, one or more machine learning models may be trained toupdate all or part of the transaction information within a contractconcerning an energy transaction (e.g., with approval from one or moreparties of the energy transaction). For example, the machine learningmodel may be configured to update volume information, price information,and the like based on real-world operating conditions (e.g., productionconditions, market conditions, financial conditions for one or moreparties, energy resource usage conditions, and the like).

Furthermore, the system 400 and related DLT may be used to continuemonitoring other aspects of the energy transaction after a transactionhas been negotiating. For example, the system 400 may be furtherconfigured to monitor or execute one or more of a nomination process; aconfirmation process; a scheduling process; a reconciliation process;billing and payment processes; and imbalance resolution processes.

For example, a request for transportation (e.g., of an energy resource)may be submitted electronically by node 1 (e.g., a seller or shipper).This request may serve as a nomination, which can be effective forvarious time periods such as a current day, a future day, a day in thepast, and the like depending on one or more regulatory requirements(e.g., the North American Energy Standards Board (NAESB) determinedcycles). Certain standards (e.g., Federal Energy Regulatory Commission(FERC) standards) may regulate the nomination deadlines for energytransactions, relevant information to be included within nominations,and/or communication methods to be used in transmitting or receivingnominations. For example, the request for transportation may includecontract volume, receipt and delivery locations, intraday, future, andpast day periods and the like.

A distributed ledger may receive information from multiple parties(e.g., as transactions received via interfaces 402, from internal orexternal storage systems). Optimization systems may analyze the receivedinformation to optimize the receipts of all parties, recognizing receiptand delivery priorities, commodity costs, shipping costs, fuel, othercosts, and the like. The optimization systems may then determine anappropriate period for the nomination and the cycle during which thenomination should be submitted and submits the nomination at theappropriate time. Any transaction party may observe the status of theenergy transaction at any time by analyzing transaction and associatedmetadata added to the distributed ledger.

In the confirmation process the transacting agents' submittednominations are approved with regard to parties, contracts, locationsand volumes while considering the regulatory (e.g., NAESB) cycles. Forexample, the system 400 may receive the parameters confirmed by theproducer, pipeline and/or distributor and may compare the receivedparameters to the nomination submitted to ensure the parametersaccurately reflect the nomination (and/or vice-versa).

Official communications from the system 400 may be transmitted via emailand a simultaneous indicator may be depicted in a user interface 402 toindicate that the confirmation process is completed. Related records maybe stored on the distributed ledger to finalize the confirmationprocess.

Scheduling may occur when a scheduling process (e.g., a schedulingprocess executing on a computing device associated with a transporter ofthe energy resource) schedules one or more nominations after anevaluation process. Priority of service (PoS) for the scheduling processmay be sorted based on one or more of firm, non-secondary reverse path(NSRP), secondary firm and interruptible. Evaluations by the schedulingprocess may be made based on one or more of shipper's contract rights,contract capacity, constraints, confirmations, elapsed pro ratascheduled quantity (EPSQ), storage rights and pool balancing specifiedin the shipper's contract and the pipeline or distributor's tariffs. Thescheduling process may then provide the system (e.g., via thedistributed ledger 450) the volumes scheduled. If the scheduled andnominated volumes do not balance, the system 400 may execute anoptimization algorithm to produce an additional nomination. If asolution is not produced, the transporter may be notified.

When energy resources are delivered, one or more meter devices mayrecord the amount of energy resource (e.g., natural gas) delivered andreceived among all parties. If a received amount of an energy resourcedoes not equal the nominated shipping volumes and actual consumption, an“imbalance” is recorded, which may require additional reconciliation.Reconciliation options may be governed by an operational balancingagreement (OBA), which may contain an imbalance section describing howimbalances may be reconciled. The transporter may also provide thesystem with one or more of platform receipt, delivery, storage, fuel,park/loan, and imbalance measurements as they become available forparticular time periods (e.g., one day, one week, one month, etc.).Records of received information may be stored both on the distributedledger and on one or more databases. Delivery reports and the like mayalso be generated at this stage.

The OBA may give authorization for automated, final resolution of anydiscrepancy between measured and scheduled quantities at a node to theshipper's OBA Agent. Reconciliation options may include one or more of100% in kind repayment, 100% cash payment, and a hybrid of the two. Ifan imbalance exists, the system 400 may run an optimization algorithmfor a time period (e.g., one day, one week, one month) to assess whethercash-out, in kind, trading, or a hybrid approach is preferable. Ifcash-out is selected, the system 400 may automatically initiate anelectronic funds transfer to the billing party's financial institution.If in kind and/or trading is selected, the system 400 may run anoptimization algorithm to create and submit a nomination for thediscrepancy. The UI may display a status and condition of thereconciliation process.

Transporters may receive invoices for their cash-out, commodity anddemand charges at the end of the month and may initiate payment. Forexample, a supplier, pipeline or distributor may provide the system 400with amounts due for a preceding time period (e.g., a day, a week, amonth, etc.). The system 400 may verify these amounts (e.g., based oninformation stored on the distributed ledger 450. The system 400 mayalso initiate an electronic funds transfer to the billing party'sfinancial institution for the indicated amount.

The system 400 may also generate invoices and an indication of aresponsible agent for issued payments. Such records may be stored (e.g.,on the distributed ledger, within a database or other storage system).In certain instances, the system 400 may also perform taxation and auditprocesses (e.g., when requested by a user).

Technical data and/or financial data may also be received and stored forfuture use. For example, data regarding nominations, fulfillment,discrepancies, and the like may be used to train one or more of themachine learning models discussed herein.

FIG. 6 depicts a method 600 for originating, negotiating and executing acontract for an energy transaction according to an exemplary embodimentof the present disclosure. The method 600 may be implemented on acomputer system, such as the system 400. The method 600 may also beimplemented by a set of instructions stored on a computer readablemedium that, when executed by a processor, cause the computer system toperform the method 600. Although the examples below are described withreference to the flowchart illustrated in FIG. 6, many other methods ofperforming the acts associated with FIG. 6 may be used. For example, theorder of some of the blocks may be changed, certain blocks may becombined with other blocks, one or more of the blocks may be repeated,and some of the blocks described may be optional.

The method 600 may begin with receiving a first request to originate acontract associated with energy transaction (block 602). For example,the first request may be received from a first computing deviceassociated with a first party of the energy transaction. The firstrequest may include a first draft of the contract. For example, thefirst draft may be prepared based on a contract template associated witha contract type for the energy transaction.

A first transaction may be added to a distributed ledger (block 604).The first transaction may be generated at least in part based oncontents of the first draft of the contract. For example, the firsttransaction may include an identifier of the first party and anidentifier of a second party associated with the energy transaction.

Transaction information regarding the energy transaction may be received(block 606). For example, the transaction information may be receivedfrom the first computing device and/or a second computing deviceassociated with the second party of the transaction. The transactioninformation may include one or more of volume information, priceinformation, and/or delivery point information.

A second draft of the contract may be generated based on the transactioninformation (block 608). For example, one or both of the first computingdevice and the second computing device (or another computing deviceassociated with the system 400) may generate the second draft of thecontract by adding the transaction information to corresponding fieldswithin the contract template.

A second transaction may be added to the distributed ledger (block 610).For example, the second transaction may be generated at least in partbased on contents of the second draft of the contract. As a specificexample, the second transaction may include a copy of one or more itemsof the transaction information (e.g., items added to the second draft ofthe contract). In certain instances, additional transaction informationmay be received regarding the energy transaction. In such instances,blocks 606, 608, 610 may be repeated.

A request may be received to finalize the contract (block 612). Forexample, the request to finalize the contract may be received from thefirst computing device and/or the second computing device. In certaininstances, the first computing device may submit the request to finalizethe contract and the second computing device may subsequently submit arequest to finalize the contract (or vice versa).

A third transaction may be added to the distributed ledger (block 614).For example, the third transaction may be generated at least in partbased on the contents of the finalized contract. As a specific example,the third transaction may include a copy of all or part of thetransaction information included within the finalized contract.Additionally or alternatively, the third transaction may include a hashof an image of the finalized contract, which may be used to authenticatethe finalized contract (e.g., after retrieving a copy of the finalizedcontract from another storage device).

In this way, the method 600 may enable negotiation of and storage ofcontracts relating to energy transactions (or other types oftransactions) using a distributed ledger. As explained further above,the techniques used to generate the transactions added to thedistributed ledger may reduce the overall information required to bestored on the distributed ledger, improving scalability andinteroperability of these techniques. Furthermore, the method 600 mayenable storage of an immutable copy of relevant information regardingthe contracts, including information that may be used to validate othercopies of the finalized contract.

FIG. 7 illustrates an example computer system 700 that may be utilizedto implement one or more of the devices and/or components discussedabove, such as the business application layer 302 and componentsthereof, the middleware layer 308 and components thereof, thedistributed ledger and machine learning layer 314 and componentsthereof, the front-end user interface 402, and components thereof, theproxy service 410, the middleware layer API 412 and components thereof,the distributed ledger layer 414 and components thereof, the relationaldatabase server 416, the relational data storage 418, the static filedeployment, the file storage system 422, and/or the elastic file storage424. In particular embodiments, one or more computer systems 700 performone or more operations of one or more methods described or illustratedherein. In particular embodiments, one or more computer systems 700provide the functionalities described or illustrated herein. Inparticular embodiments, software running on one or more computer systems700 performs one or more operations of one or more methods described orillustrated herein or provides the functionalities described orillustrated herein. Particular embodiments include one or more portionsof one or more computer systems 700. Herein, a reference to a computersystem may encompass a computing device, and vice versa, whereappropriate. Moreover, a reference to a computer system may encompassone or more computer systems, where appropriate.

This disclosure contemplates any suitable number of computer systems700. This disclosure contemplates the computer system 700 taking anysuitable physical form. As example and not by way of limitation, thecomputer system 700 may be an embedded computer system, a system-on-chip(SOC), a single-board computer system (SBC) (such as, for example, acomputer-on-module (COM) or system-on-module (SOM)), a desktop computersystem, a laptop or nodebook computer system, an interactive kiosk, amainframe, a mesh of computer systems, a mobile telephone, a personaldigital assistant (PDA), a server, a tablet computer system, anaugmented/virtual reality device, a quantum computing device, aninternet of things (TOT) computing device, or a combination of two ormore of these. Where appropriate, the computer system 700 may includeone or more computer systems 700; be unitary or distributed; spanmultiple locations; span multiple machines; span multiple data centers;or reside in a cloud, which may include one or more cloud components inone or more networks. Where appropriate, one or more computer systems700 may perform without substantial spatial or temporal limitation oneor more steps of one or more methods described or illustrated herein. Asan example and not by way of limitation, one or more computer systems700 may perform in real time or in batch mode one or more steps of oneor more methods described or illustrated herein. One or more computersystems 700 may perform at different times or at different locations oneor more steps of one or more methods described or illustrated herein,where appropriate.

In particular embodiments, computer system 700 includes a processor 706,memory 704, storage 708, an input/output (I/O) interface 710, and acommunication interface 712. Although this disclosure describes andillustrates a particular computer system having a particular number ofparticular components in a particular arrangement, this disclosurecontemplates any suitable computer system having any suitable number ofany suitable components in any suitable arrangement.

In particular embodiments, the processor 706 includes hardware forexecuting instructions, such as those making up a computer program. Asan example and not by way of limitation, to execute instructions, theprocessor 706 may retrieve (or fetch) the instructions from an internalregister, an internal cache, memory 704, or storage 708; decode andexecute the instructions; and then write one or more results to aninternal register, internal cache, memory 704, or storage 708. Inparticular embodiments, the processor 706 may include one or moreinternal caches for data, instructions, or addresses. This disclosurecontemplates the processor 706 including any suitable number of anysuitable internal caches, where appropriate. As an example and not byway of limitation, the processor 706 may include one or more instructioncaches, one or more data caches, and one or more translation lookasidebuffers (TLBs). Instructions in the instruction caches may be copies ofinstructions in memory 704 or storage 708, and the instruction cachesmay speed up retrieval of those instructions by the processor 706. Datain the data caches may be copies of data in memory 704 or storage 708that are to be operated on by computer instructions; the results ofprevious instructions executed by the processor 706 that are accessibleto subsequent instructions or for writing to memory 704 or storage 708;or any other suitable data. The data caches may speed up read or writeoperations by the processor 706. The TLBs may speed up virtual-addresstranslation for the processor 706. In particular embodiments, processor706 may include one or more internal registers for data, instructions,or addresses. This disclosure contemplates the processor 706 includingany suitable number of any suitable internal registers, whereappropriate. Where appropriate, the processor 706 may include one ormore arithmetic logic units (ALUs), be a multi-core processor, orinclude one or more processors 702. Although this disclosure describesand illustrates a particular processor, this disclosure contemplates anysuitable processor.

In particular embodiments, the memory 704 includes main memory forstoring instructions for the processor 706 to execute or data forprocessor 706 to operate on. As an example, and not by way oflimitation, computer system 700 may load instructions from storage 708or another source (such as another computer system 700) to the memory704. The processor 706 may then load the instructions from the memory704 to an internal register or internal cache. To execute theinstructions, the processor 706 may retrieve the instructions from theinternal register or internal cache and decode them. During or afterexecution of the instructions, the processor 706 may write one or moreresults (which may be intermediate or final results) to the internalregister or internal cache. The processor 706 may then write one or moreof those results to the memory 704. In particular embodiments, theprocessor 706 executes only instructions in one or more internalregisters or internal caches or in memory 704 (as opposed to storage 708or elsewhere) and operates only on data in one or more internalregisters or internal caches or in memory 704 (as opposed to storage 708or elsewhere). One or more memory buses (which may each include anaddress bus and a data bus) may couple the processor 706 to the memory704. The bus may include one or more memory buses, as described infurther detail below. In particular embodiments, one or more memorymanagement units (MMUs) reside between the processor 706 and memory 704and facilitate accesses to the memory 704 requested by the processor706. In particular embodiments, the memory 704 includes random accessmemory (RAM). This RAM may be volatile memory, where appropriate. Whereappropriate, this RAM may be dynamic RAM (DRAM) or static RAM (SRAM).Moreover, where appropriate, this RAM may be single-ported ormulti-ported RAM. This disclosure contemplates any suitable RAM. Memory704 may include one or more memories 804, where appropriate. Althoughthis disclosure describes and illustrates particular memoryimplementations, this disclosure contemplates any suitable memoryimplementation.

In particular embodiments, the storage 708 includes mass storage fordata or instructions. As an example and not by way of limitation, thestorage 708 may include a hard disk drive (HDD), a floppy disk drive,flash memory, an optical disc, a magneto-optical disc, magnetic tape, ora Universal Serial Bus (USB) drive or a combination of two or more ofthese. The storage 708 may include removable or non-removable (or fixed)media, where appropriate. The storage 708 may be internal or external tocomputer system 700, where appropriate. In particular embodiments, thestorage 708 is non-volatile, solid-state memory. In particularembodiments, the storage 708 includes read-only memory (ROM). Whereappropriate, this ROM may be mask-programmed ROM, programmable ROM(PROM), erasable PROM (EPROM), electrically erasable PROM (EEPROM),electrically alterable ROM (EAROM), or flash memory or a combination oftwo or more of these. This disclosure contemplates mass storage 708taking any suitable physical form. The storage 708 may include one ormore storage control units facilitating communication between processor706 and storage 708, where appropriate. Where appropriate, the storage708 may include one or more storages 708. Although this disclosuredescribes and illustrates particular storage, this disclosurecontemplates any suitable storage.

In particular embodiments, the I/O Interface 710 includes hardware,software, or both, providing one or more interfaces for communicationbetween computer system 700 and one or more I/O devices. The computersystem 700 may include one or more of these I/O devices, whereappropriate. One or more of these I/O devices may enable communicationbetween a person and computer system 700. As an example and not by wayof limitation, an I/O device may include a keyboard, keypad, microphone,monitor, screen, display panel, mouse, printer, scanner, speaker, stillcamera, stylus, tablet, touch screen, trackball, video camera, anothersuitable I/O device or a combination of two or more of these. An I/Odevice may include one or more sensors. Where appropriate, the I/OInterface 710 may include one or more device or software driversenabling processor 706 to drive one or more of these I/O devices. TheI/O interface 710 may include one or more I/O interfaces 710, whereappropriate. Although this disclosure describes and illustrates aparticular I/O interface, this disclosure contemplates any suitable I/Ointerface or combination of I/O interfaces.

In particular embodiments, communication interface 712 includeshardware, software, or both providing one or more interfaces forcommunication (such as, for example, packet-based communication) betweencomputer system 700 and one or more other computer systems 700 or one ormore networks 714. As an example and not by way of limitation,communication interface 712 may include a network interface controller(NIC) or network adapter for communicating with an Ethernet or any otherwire-based network or a wireless NIC (WNIC) or wireless adapter forcommunicating with a wireless network, such as a Wi-Fi network. Thisdisclosure contemplates any suitable network 714 and any suitablecommunication interface 712 for it. As an example and not by way oflimitation, the network 714 may include one or more of an ad hocnetwork, a personal area network (PAN), a local area network (LAN), awide area network (WAN), a metropolitan area network (MAN), or one ormore portions of the Internet or a combination of two or more of these.One or more portions of one or more of these networks may be wired orwireless. As an example, computer system 700 may communicate with awireless PAN (WPAN) (such as, for example, a Bluetooth® WPAN), a WI-FInetwork, a WI-MAX network, a cellular telephone network (such as, forexample, a Global System for Mobile Communications (GSM) network), orany other suitable wireless network or a combination of two or more ofthese. Computer system 700 may include any suitable communicationinterface 712 for any of these networks, where appropriate.Communication interface 712 may include one or more communicationinterfaces 712, where appropriate. Although this disclosure describesand illustrates a particular communication interface implementations,this disclosure contemplates any suitable communication interfaceimplementation.

The computer system 700 may also include a bus. The bus may includehardware, software, or both and may communicatively couple thecomponents of the computer system 700 to each other. As an example andnot by way of limitation, the bus may include an Accelerated GraphicsPort (AGP) or any other graphics bus, an Enhanced Industry StandardArchitecture (EISA) bus, a front-side bus (FSB), a HYPERTRANSPORT (HT)interconnect, an Industry Standard Architecture (ISA) bus, an INFINIBANDinterconnect, a low-pin-count (LPC) bus, a memory bus, a Micro ChannelArchitecture (MCA) bus, a Peripheral Component Interconnect (PCI) bus, aPCI-Express (PCIe) bus, a serial advanced technology attachment (SATA)bus, a Video Electronics Standards Association local (VLB) bus, oranother suitable bus or a combination of two or more of these. The busmay include one or more buses, where appropriate. Although thisdisclosure describes and illustrates a particular bus, this disclosurecontemplates any suitable bus or interconnect.

Herein, a computer-readable non-transitory storage medium or media mayinclude one or more semiconductor-based or other types of integratedcircuits (ICs) (e.g., field-programmable gate arrays (FPGAs) orapplication-specific ICs (ASICs)), hard disk drives (HDDs), hybrid harddrives (HHDs), optical discs, optical disc drives (ODDs),magneto-optical discs, magneto-optical drives, floppy diskettes, floppydisk drives (FDDs), magnetic tapes, solid-state drives (SSDs),RAM-drives, SECURE DIGITAL cards or drives, any other suitablecomputer-readable non-transitory storage media, or any suitablecombination of two or more of these, where appropriate. Acomputer-readable non-transitory storage medium may be volatile,non-volatile, or a combination of volatile and non-volatile, whereappropriate.

Herein, “or” is inclusive and not exclusive, unless expressly indicatedotherwise or indicated otherwise by context. Therefore, herein, “A or B”means “A, B, or both,” unless expressly indicated otherwise or indicatedotherwise by context. Moreover, “and” is both joint and several, unlessexpressly indicated otherwise or indicated otherwise by context.Therefore, herein, “A and B” means “A and B, jointly or severally,”unless expressly indicated otherwise or indicated otherwise by context.

The scope of this disclosure encompasses all changes, substitutions,variations, alterations, and modifications to the example embodimentsdescribed or illustrated herein that a person having ordinary skill inthe art would comprehend. The scope of this disclosure is not limited tothe example embodiments described or illustrated herein. Moreover,although this disclosure describes and illustrates respectiveembodiments herein as including particular components, elements,feature, functions, operations, or steps, any of these embodiments mayinclude any combination or permutation of any of the components,elements, features, functions, operations, or steps described orillustrated anywhere herein that a person having ordinary skill in theart would comprehend. Furthermore, reference in the appended claims toan apparatus or system or a component of an apparatus or system beingadapted to, arranged to, capable of, configured to, enabled to, operableto, or operative to perform a particular function encompasses thatapparatus, system, component, whether or not it or that particularfunction is activated, turned on, or unlocked, as long as thatapparatus, system, or component is so adapted, arranged, capable,configured, enabled, operable, or operative. Additionally, although thisdisclosure describes or illustrates particular embodiments as providingparticular advantages, particular embodiments may provide none, some, orall of these advantages.

1. A method comprising: receiving, from a first computing deviceassociated with a first party of an energy transaction, a first requestto originate a contract associated with the energy transaction, whereinthe first request includes a first draft of the contract; adding a firsttransaction to a distributed ledger, the first transaction generated atleast in part based on contents of the first draft of the contract;receiving, from at least one of the first computing device and a secondcomputing device associated with a second party of the energytransaction, transaction information regarding the energy transaction;generating a second draft of the contract based on the transactioninformation; and adding a second transaction to the distributed ledger,the second transaction generated at least in part based on contents ofthe second draft of the contract.
 2. The method of claim 1, furthercomprising: receiving, from at least one of the first computing deviceand the second computing device, a request to finalize the contract; andadding a third transaction to the distributed ledger, the thirdtransaction generated at least in part based on a finalized version ofthe contract.
 3. The method of claim 2, wherein the third transactionincludes (i) an identifier of the first party, (ii) an identifier of thesecond party, and (iii) a hash generated at least in part based on animage of the finalized version of the contract.
 4. The method of claim1, further comprising: receiving, prior to receiving the first request,a second request to create the contract, wherein the second requestspecifies a contract type; and transmitting, to the first computingdevice, a contract template associated with the contract type.
 5. Themethod of claim 4, further comprising: adding a fourth transaction tothe distributed ledger, the fourth transaction generated at least inpart based on the contract template.
 6. The method of claim 5, whereinthe fourth transaction includes (i) an identifier of the first party and(ii) an identifier of the contract type.
 7. The method of claim 4,wherein generating the second draft of the contract includes adding thetransaction information to one or more corresponding fields within thecontract template.
 8. The method of claim 1, wherein the firsttransaction includes (i) an identifier of a first party associated withthe first computing device and (ii) an identifier of the second party.9. The method of claim 1, wherein the transaction information includestrade volume information and/or price information.
 10. The method ofclaim 1, wherein the first party is a seller and the second party is abuyer.
 11. The method of claim 10, wherein the buyer is identified usingan auction system.
 12. The method of claim 1, wherein the secondtransaction includes (i) an identifier of the of the first party, (ii)an identifier of the second party, and (iii) a copy of at least a subsetof the transaction information.
 13. The method of claim 1, furthercomprising executing one or more of a nomination process, a confirmationprocess, a scheduling process, a reconciliation process, billing andpayment processes, and imbalance resolution processes.
 14. The method ofclaim 1, further comprising storing, in a database, a copy of at leastone of the first draft of the contract, the second draft of thecontract, the first transaction and the second transaction.
 15. A systemcomprising: a processor; and a memory storing instructions which, whenexecuted by the processor, cause the processor to: receive, from a firstcomputing device associated with a first party of an energy transaction,a first request to originate a contract associated with the energytransaction, wherein the first request includes a first draft of thecontract; add a first transaction to a distributed ledger, the firsttransaction generated at least in part based on contents of the firstdraft of the contract; receive, from at least one of the first computingdevice and a second computing device associated with a second party ofthe energy transaction, transaction information regarding the energytransaction; generate a second draft of the contract based on thetransaction information; and add a second transaction to the distributedledger, the second transaction generated at least in part based oncontents of the second draft of the contract.
 16. The system of claim15, wherein the instructions further cause the processor to: receive,from at least one of the first computing device and the second computingdevice, a request to finalize the contract; and add a third transactionto the distributed ledger, the third transaction generated at least inpart based on a finalized version of the contract.
 17. The system ofclaim 16, wherein the third transaction includes (i) an identifier ofthe first party, (ii) an identifier of the second party, and (iii) ahash generated at least in part based on an image of the finalizedversion of the contract.
 18. The system of claim 15, wherein theinstructions further cause the processor to: receive, prior to receivingthe first request, a second request to create the contract, wherein thesecond request specifies a contract type; and transmit, to the firstcomputing device, a contract template associated with the contract type.19. The system of claim 18, wherein the instructions further cause theprocessor to: add a fourth transaction to the distributed ledger, thefourth transaction generated at least in part based on the contracttemplate.
 20. The system of claim 19, wherein the fourth transactionincludes (i) an identifier of the first party and (ii) an identifier ofthe contract type.